requisites

Please be sure to read Pre-requisites - test quality standards and follow those guidelines.

Arquillian container configuration

See AS 7.1 managed container adapter refrence.

ManagementClient and ModelNode usage example

final ModelNode operation = new ModelNode();
operation.get(ModelDescriptionConstants.OP).set(ModelDescriptionConstants.READ_RESOURCE_OPERATION);
operation.get(ModelDescriptionConstants.OP_ADDR).set(address);
operation.get(ModelDescriptionConstants.RECURSIVE).set(true);

final ModelNode result = managementClient.getControllerClient().execute(operation);
Assert.assertEquals(ModelDescriptionConstants.SUCCESS, result.get(ModelDescriptionConstants.OUTCOME).asString());

ManagementClient can be obtained as described below.

Arquillian features available in tests

@ServerSetup

TBD

@ContainerResource private ManagementClient managementClient;
final ModelNode result = managementClient.getControllerClient().execute(operation);

TBD

@ArquillianResource private ManagementClient managementClient;
ModelControllerClient client = managementClient.getControllerClient();

@ArquillianResource ContainerController cc;

@Test
public void test() {
    cc.setup("test", ...properties..)
    cc.start("test")
}

<arquillian>
    <container qualifier="test" mode="manual" />
</arquillian>

// Targeted containers HTTP context.
@ArquillianResource URL url;

// Targeted containers HTTP context where servlet is located.
@ArquillianResource(SomeServlet.class) URL url;

// Targeted containers initial context.
@ArquillianResource InitialContext|Context context;

// The manual deployer.
@ArquillianResource Deployer deployer;

See Arquillian's Resource Injection docs for more info, https://github.com/arquillian/arquillian-examples for examples.

See also Arquillian Reference.

Note to @ServerSetup annotation: It works as expected only on non-manual containers. In case of manual mode containers it calls setup() method after each server start up which is right (or actually before deployment), but the tearDown() method is called only at AfterClass event, i.e. usually after your manual shutdown of the server. Which limits you on the ability to revert some configuration changes on the server and so on. I cloned the annotation and changed it to fit the manual mode, but it is still in my github branch :)

Properties available in tests

Negative tests

To test invalid deployment handling:  @ShouldThrowException

Currently doesn't work due to WFLY-673.

optionally you might be able to catch it using the manual deployer

@Deployment(name = "X", managed = false) ...

@Test
public void shouldFail(@ArquillianResource Deployer deployer) throws Exception {
  try {
    deployer.deploy("X")
  }
  catch(Exception e) {
   // do something
  }
}

Clustering tests (WFLY-616)

You need to deploy the same thing twice, so two deployment methods that just return the same thing.
And then you have tests that run against each.

@Deployment(name = "deplA", testable = false)
    @TargetsContainer("serverB")
    public static Archive<?> deployment()

    @Deployment(name = "deplB", testable = false)
    @TargetsContainer("serverA")
    public static Archive<?> deployment(){ ... }

    @Test
    @OperateOnDeployment("deplA")
    public void testA(){ ... }

    @Test
    @OperateOnDeployment("deplA")
    public void testA() {...}

How to get the tests to master

• First of all, be sure to read the "Before you add a test" section.

• Fetch the newest mater: git fetch upstream  # Provided you have the jbossas/jbossas GitHub repo as a remote called 'upstream'.

• Rebase your branch: git checkout WFLY-1234-your-branch;  git rebase upstream/master

• Run whole testsuite (integration-tests -DallTests). You may use https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/wildfly-as-testsuite-RHEL-matrix-openJDK7/lastCompletedBuild/testReport/.

  • If any tests fail and they do not fail in master, fix it and go back to the "Fetch" step.

• Push to a new branch in your GitHub repo: git push origin WFLY-1234-new-XY-tests

• Create a pull-request on GitHub. Go to your branch and click on "Pull Request". 

  • If you have a jira, start the title with it, like - WFLY-1234 New tests for XYZ.

  • If you don't, write some apposite title. In the description, describe in detail what was done and why should it be merged. Keep in mind that the diff will be visible under your description.

• Keep the branch rebased daily until it's merged (see the Fetch step). If you don't, you're dramatically decreasing chance to get it merged.

• There's a mailing list, jbossas-pull-requests, which is notified of every pull-request.

• You might have someone with merge privileges to cooperate with you, so they know what you're doing, and expect your pull request.

• When your pull request is reviewed and merged, you'll be notified by mail from GitHub.

• You may also check if it was merged by the following:  git fetch upstream; git cherry <branch>  ## Or git branch --contains{{<branch> - see}} here

• Your commits will appear in master. They will have the same hash as in your branch.

  • You are now safe to delete both your local and remote branches: git branch -D WFLY-1234-your-branch; git push origin :WFLY-1234-your-branch